home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 11501 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.8 KB  |  60 lines
  1. Newsgroups: comp.lang.c
  2. Path: news.uunet.ca!wildcan!sq!msb
  3. From: msb@sq.com (Mark Brader)
  4. Subject: Re: Determining the length of an int in string form
  5. Message-ID: <1996Mar24.195142.14175@sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <3146D058.DD7@cbm.com> <4ipd9k$ep8@news.erinet.com> <Pine.SOL.3.91.960320230310.14476C-100000@darwin.UCSC.EDU> <Pine.SOL.3.91.960321120638.3532A-100000@darwin.UCSC.EDU>
  8. Date: Sun, 24 Mar 1996 19:51:42 GMT
  9.  
  10. If the motivation for the question is simply to find out how large a
  11. buffer you need to use to sprintf() the int into it, then don't bother.
  12.  
  13. Just use a buffer of (sizeof(int) * CHAR_BIT + 2) / 3 + 1 + 1 bytes,
  14. like it says in the FAQ list, and you're done.  The only problem would
  15. be if you're still using a pre-ANSI system and don't have CHAR_BIT
  16. available; in that case I'd suggest finding out what it is (that's
  17. trivial) and providing it through a system-dependent header file of
  18. your own, or of course, getting a newer C implementation.
  19.  
  20. If you actually need to store a whole bunch of ints and are concerned
  21. about space efficiency, then store them *as* ints, not strings.
  22.  
  23. If this is really only part of the question and you actually need to
  24. store a whole lot of strings each of which contains the string version
  25. of an int as part of its content, then this technique:
  26.  
  27. "royaltey@darwin.UCSC.EDU" writes:
  28. > Another alternative is to sprintf the string into a static buffer
  29. > known to be long enough to hold any int, strlen the result to find the
  30. > actual length, malloc a suitably sized buffer, then strcpy the result
  31. > to the malloc'ed buffer. 
  32.  
  33. (with the appropriate modification for your actual situation) is generally
  34. the best and easiest.
  35.  
  36. However, note that there may actually be no difference betwen malloc()ing,
  37. say, 5 bytes for this string and 8 bytes for that one.  That is, it's
  38. entirely possible that malloc() rounds the number of bytes allocated up
  39. to a multiple of some convenient amount.  In general, it's not worth
  40. sweating to get malloc()ed storage down to the exact minimum size that
  41. the data being stored really needs, if it's any trouble to calculate it.
  42.  
  43. Maurizio Loreti (loreti@padova.infn.it)'s suggestion in another branch of
  44. the thread:
  45.  
  46. | However, the solution is to fprintf the integer to the bit bucket
  47. | (i.e. /dev/null, NLA0:, NIL or what is called on your system) and to
  48. | use its return value.
  49.  
  50. is also feasible, but inherently system-dependent, and fails on systems
  51. that don't *have* a bit bucket.
  52.  
  53. -- 
  54. Mark Brader             We say, "But it wasn't designed to do that!";
  55. SoftQuad Inc.           our managers say, "Our customers want this!";
  56. msb@sq.com              we say, "Small is beautiful!"; and they say,
  57. Toronto                 "Money is beautiful!"       -- Andrew Tannenbaum
  58.  
  59. My text in this article is in the public domain.
  60.